DMS migration failing? How to debug Oracle to Cloud SQL network errors, layer-by-layer (OSI model guide)

For database engineers stepping into cloud migrations for the first time, networking is the silent troublemaker. Most tutorials skip straight to configuring connection profiles, but if the network underneath isn’t right, DMS will fail in ways that feel cryptic and random.

This guide uses the OSI model as a practical debugging framework — not as abstract theory — to help you pinpoint exactly where an Oracle to Cloud SQL PostgreSQL migration is breaking down, layer by layer.

From VPC routing gaps at Layer 3 to SSL certificate mismatches at Layer 6, you’ll learn how to read DMS error messages like a map, and how a 15-minute pre-flight connectivity check can save you an entire day of confusion.

Before we begin – a quick introduction

I want to start with a confession: a few years back, I went deep on networking. I mean really deep – TCP/IP internals, packet capture with Wireshark, OSI layers until I could recite them in my sleep.

For a while, it felt like a superpower. Network issue blocking a migration? Give me a day or two and I’d have it pinpointed. I could see what was happening beneath the surface in a way that most database engineers around me couldn’t.

Then life got busy, projects piled up, and I drifted back to focusing on the database layer: schemas, indexes, query plans. That networking muscle I’d been using so much of, began to fade.

Fast forward to working with Google Database Migration Service (DMS) on an Oracle to Cloud SQL PostgreSQL migration, and guess what came back to bite me? It was the network – every single time.

So I’m writing this series partly to share what I’ve learned, and partly to rebuild because I think the journey of why networking fundamentals matter is just as useful as the technical details themselves. Especially if you’re a database engineer stepping into cloud migrations for the first time.

The three-point connectivity problem

When you set up DMS for an Oracle to Cloud SQL migration, you’re not dealing with a simple two-node connection. You have three distinct players:

Each of those relationships – DMS to Oracle, and DMS to Cloud SQL – have their own networking requirements, failure modes, and error messages that can send you down the wrong rabbit hole if you don’t understand what’s happening at a lower level.

Most tutorials jump straight to “configure your connection profile” but, if the network isn’t right underneath, DMS will fail in ways that feel cryptic and random. The error messages bubble up from deep in the stack and don’t always tell you where the real problem is.

That’s where the OSI model comes in – and it’s what we’ll examine next.

What is the OSI model (and why should database engineers care)?

If you studied networking at any point, you’ve seen this before. It’s much more than just ‘theory for theory’s sake’.

The OSI (Open Systems Interconnection) model describes how data travels from one system to another in seven distinct layers:

One important thing to know before we go further: the OSI model is a thinking tool, not a rigid rulebook. Real-world protocols don’t map to it perfectly.

And TCP/IP – which is what everything actually runs on – doesn’t cleanly separate into seven layers. Practitioners often collapse layers together, which is why you’ll hear people talk about “Layer 3/4” in the same breath. What matters is the mental model it gives you for debugging.

The key insight: layers are sequential

The single most useful thing to understand about the OSI model for debugging purposes, is this: a failure at a lower layer prevents every layer above it from running.

Think about what that means in practice. If Layer 3 (Network) fails – meaning DMS cannot route a packet to Oracle’s IP address – then Layers 4, 5, 6, and 7 never get a chance to do anything. Oracle never sees the connection attempt, the TNS (Transparent Network Substrate) listener never responds, and SSL never negotiates.

The result? Authentication never happens.

This gives you a powerful debugging process. Simply read the error message and ask yourself, how far did the connection actually get before it failed? The answer tells you which layer to focus on.

How to read error messages through an OSI lens

Let me walk through what a failure at each layer actually looks like in the context of a DMS to Oracle connection. This is the reference I wish I’d had when I started.

Layer 1 (physical) – almost invisible in cloud migrations

Layer 1 failures are about raw physical signal transmission – bad cables, failed network interfaces, disconnected fiber. In a fully cloud-based migration, Layer 1 is Google’s problem, not yours. Their infrastructure handles it entirely.

The one scenario where Layer 1 could affect you is if your Oracle source is on-premises and connected to Google Cloud via Dedicated Interconnect. A bad transceiver or damaged fiber on that cross-connect could cause a Layer 1 failure. But that is some you’d be escalating to your physical network team at that point, not debugging it yourself.

If Layer 1 fails, you won’t see an application error at all. You’d see it in operating system logs:

eth0: Link is down

No carrier detected

NIC reported media disconnected

These show up in dmesg or /var/log/syslog, not in DMS or Oracle logs. Most database engineers never look there –  which is exactly why Layer 1 failures feel so mysterious when they do occur.

Layer 2 (data link) – also largely abstracted in cloud

Layer 2 handles MAC addresses and frame delivery between devices on the same local network segment. In a Google Cloud VPC environment, this is again abstracted away from you completely.

A Layer 2 failure produces almost no useful information at the application level. You get:

Connection timed out

Nothing else. The application sent data out and nothing came back – but it has no visibility into why. This makes Layer 2 failures hard to distinguish from Layer 3 failures at first glance.

The difference shows up when you go lower – a Layer 2 failure means an ARP request (asking “who has this IP?”) goes unanswered, whereas a Layer 3 failure means the packet routes out but can’t find a path to the destination.

In practice, for cloud migrations: if you see a generic timeout with no other information, suspect Layer 3 before Layer 2.

Layer 3 (network) – high relevance for DMS migrations

This is where things get real for cloud migrations. Layer 3 is about IP addressing and routing – can DMS actually get a packet to the Oracle host’s IP address?

Common Layer 3 failure scenarios in DMS migrations:

A Layer 3 failure looks like:

Connection timed out

No route to host

The diagnostic move at Layer 3: from a VM inside the DMS VPC, run ping <oracle-host-ip> and ip route get <oracle-host-ip>.

One important caveat: ICMP is often blocked by GCP VPC firewall rules, so a ping failure alone does not confirm a routing problem. Use ip route get to verify the routing table independently. 

If neither ping nor a route entry exists for the Oracle subnet, you have a routing problem to solve before DMS will ever work.

Layer 4 (transport) – high relevance for DMS migrations

Layer 4 is TCP – the three-way handshake that establishes a connection before any data is exchanged. Your client sends SYN, the server responds with SYN-ACK, your client completes with ACK. Only after this handshake completes can anything else happen.

Common Layer 4 failure scenarios:

A Layer 4 failure looks like:

IO Error: The Network Adapter could not establish the connection

Connection refused

Notice: no TNS, no SSL mention. The TCP handshake never completed. The diagnostic move at Layer 4: use telnet or nc from a VM in the DMS VPC to test whether port 1521 on the Oracle host is reachable.

# Test Layer 4 connectivity to Oracle listener

nc -zv <oracle-host-ip> 1521

# Or with telnet

telnet <oracle-host-ip> 1521

If this fails, you have a firewall or listener issue to resolve before anything else matters.

Layer 5 (session) – relevant once TCP is established

Layer 5 kicks in after the TCP connection is up. In Oracle’s world, this is the TNS (Transparent Network Substrate) negotiation – the Oracle-specific protocol that sits on top of TCP. DMS connects on port 1521, the listener responds, and then the two sides negotiate which Oracle service or security identifier (SID) to connect to.

Common Layer 5 failure scenarios:

A Layer 5 failure looks like:

ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

ORA-12505: TNS:listener does not currently know of SID given in connect descriptor

ORA-12516: TNS:listener could not find available handler with matching protocol stack

The key signature: TNS appears in the error. This tells you that TCP worked fine (Layer 4 succeeded), the listener picked up the connection (Layer 5 started), but the session negotiation failed. The fix is almost always in your Oracle connection string – check your service name or SID.

Layer 6 (presentation) – medium relevance (mostly SSL/TLS)

Layer 6, in theory, covers both encryption and data format translation (character encoding, serialization). In practice, for DMS migrations, you will almost exclusively encounter Layer 6 issues in the form of SSL/TLS problems. The data format translation aspect is handled transparently by drivers and rarely causes explicit errors.

Layer 6 kicks in after TCP is established and after the initial session negotiation. DMS and Oracle (or Cloud SQL) try to negotiate encryption – they need to agree on a TLS version, a cipher suite, and exchange certificates.

Common Layer 6 failure scenarios:

A Layer 6 failure looks like:

ORA-28860: Fatal SSL error

ORA-28865: SSL connection closed gracefully

SSL handshake failed: Received fatal alert: certificate_unknown

javax.net.ssl.SSLHandshakeException: PKIX path building failed

The key signature: SSL, TLS, handshake, certificate, or alert appear in the error. This tells you that TCP worked (Layer 4), TNS negotiation worked (Layer 5), but encryption setup fell apart. The fix lives in your certificate configuration, not your firewall rules.

Layer 7 (application) – wrong password, wrong schema, wrong permissions

Layer 7 is where Oracle and PostgreSQL actually speak their own protocol. If you’ve made it to a Layer 7 failure, congratulations – your network is fine. The database is reachable. Now you have a database problem.

A Layer 7 failure looks like:

ORA-01017: invalid username/password; logon denied

ORA-00942: table or view does not exist

ORA-01031: insufficient privileges

No network troubleshooting needed here: check your credentials, your schema, and your grants.

The complete reference: OSI layers in DMS migrations

The table below is the full picture in one place. Find your error message, match it to the error signature for that layer, and you immediately know where to focus. Each layer also shows what succeeded before the failure – which is just as useful, because it rules out everything below.

The pattern to memorize

As you go up the layers, error messages get more specific and more informative:

A practical habit that will save you hours

Before you run a single DMS migration job, validate connectivity at each relevant layer manually. It takes fifteen minutes and can save you an entire day of confusion.

Here’s how to do it:

Step 1 – Validate Layer 3 (routing): From a VM inside the DMS VPC, ping the Oracle host IP. If ping fails, fix your VPC routing or VPN configuration first.

Step 2 – Validate Layer 4 (transport): From the same VM, use nc or telnet to test port 1521. If this fails, fix your firewall rules first.

Step 3 – Validate Layer 5 (session): Use tnsping from the DMS network if available, or check the Oracle listener status with lsnrctl status on the Oracle host. Confirm your service name or SID is correct.

Step 4 – Validate Layer 6 (SSL): If you’ve configured SSL on either connection, test the TLS handshake with openssl s_client before DMS does it.

Only after all four pass should you configure your DMS connection profile and hit “Test Connection.” At that point, if it still fails, you’re almost certainly dealing with a Layer 7 issue – credentials, permissions, or schema.

Have you hit networking issues in a cloud database migration? I’d love to hear what tripped you up – drop a comment below or find me on LinkedIn.